Model Checking Electronic Commerce Protocols Extended Abstract

The paper develops model checking techniques to examine NetBill and Digicash. We show how model checking can nd atomicity problems by analyzing simpli ed versions of these protocols that retain crucial security problems. For our analysis we used the FDR model checker [13]. Note to reviewers: This is an extended abstract only. We anticipate that some of the work described in Section 5 will be completed by the time that the camera-ready copy of this paper is due (if it is accepted.) 1 Atomicity Properties Correctness is a prime concern for electronic commerce protocols. How can we show that a given protocol is safe for use? Here we show how to use model checking to test whether electronic commerce protocols satisfy some given atomicity properties. For verifying properties of protocols, model checking is a dramatic improvement over doing hand proofs, because it is mechanizable; it is a dramatic improvement over using state-of-the-art theorem provers because it is automatic, fast, and requires no human interaction. Moreover, we found a number of problems in proposed electronic commerce protocols using model checking. Model checking allows us to focus on just those aspects of the protocol necessary to guarantee desired properties. In doing so, we can gain a better understanding of why the protocol works and often can identify places of optimizing it. For this paper, we have chosen to check atomicity properties. In the 1995 USENIX Electronic Commerce Workshop, Camp, Sirbu, and Tygar argued that these properties are central property to electronic commerce protocols [1]. In an atomic protocol, an electronic purchase either aborts with no transfer of money and goods; or fully completes with money and goods exchanged. This work was supported in part by Defense Advanced Research Project Agency (ARPA contract F33615-93-11330), the National Science Foundation (NSF cooperative agreement IR-9411299), and by the US Postal Service. This work is the opinion of the authors and does not necessarily represent the view of their employers, funding sponsors, or the US Government. Moreover, these atomic properties are preserved even if communications fail between some of the parties, because of failure of either a communications link or a node (including the parties participating in the protocol.) Tygar [20] gave informal descriptions of three protocol properties that appear to be related to atomicity: money atomicity Money should neither be created nor destroyed by electronic commerce protocols. For example, this protocol is not money atomic: 1. Consumer sends message to consumer's bank: transfer $value to merchant; 2. Consumer's bank decrements consumer's balance by $value; 3. Consumer's bank sends message to merchant's bank: increase merchant's bank balance by $value; 4. Merchant's bank increments merchant's balance by $value. If Message 3 is not received, then the consumer's balance will have lost money without the merchant's bank having received the money. E ectively, money will be destroyed. goods atomicity A merchant should receive payment if and only if the consumer receives the goods. Goods atomicity is particularly relevant in the case of electronic goods (such as binary les) that are delivered over the network. For example this protocol is not goods atomic: 1. Consumer sends credit card number to merchant; 2. Merchant charges consumer's credit card; 3. Merchant sends electronic goods to consumer Suppose Message 3 is not received by the consumer; then she will not have received the goods for which she was charged. certi ed delivery In the case of electronic goods, both the merchant and the consumer should be able to give non-repudiable proof of the contents of the delivered goods. (We do not consider certi ed delivery in this paper.) In this paper, we discuss how to use model checking to determine whether money atomicity and goods atomicity hold of two classes of electronic commerce protocols: account-based (e.g. NetBill [4, 19]) and token-based (e.g. a simpli ed protocol inspired by Chaum's Digicash [3, 2]). We used the FDR model checker [13], though other model checkers could have been used.